@eskimo,
There's a new problem I just ran into:
If the host is a Windows server, the domain name of the mounted volume resolve to a name that I cannot use - neither directly nor with the proposed SRVResolver.
For instance, I set up a Windows server with the netbios(?) name "win-serv", and a volume named "WinServer". When I Get Info on the mounted volume, it shows as:
smb://win-serv/WinServer
When I retrieve the domain name, e.g. with statfs, the name I get is just "win-serv", but that can't be used as an IP address.
I found that I can resolve this name with the shell cmd smbutil lookup win-serv, though.
So my questions are:
Is there an API for doing what smbutil lookup does?
How do I tell that I need to use this method? I guess I could just always fall back to it when I cannot reach the server via its given name, but is there a clearer indicator that this is a WINS(?) and not a usual DNS name?
I have a related question on StackOverflow but that hasn't gotten me anywhere, either. This entire WINS/NetBIOS thing is a mystery on macOS, it seems.
The remote user name can be found in the f_mntfromname field from the statfs() call.
I found the solution myself by trial-and-error:
The NSURL resource key NSURLVolumeNameKey contains the original name. It's not clearly documented that it does, but in my tests that did return the desired result.
@eskimo,
With the code from SRVResolver I can indeed resolve QNAS._smb._tcp.local. Problem is: If the host name is a plain one, like syno.local, then I get neither an error nor a callback. And using a Timeout for a local-only NS resolve seems wrong to me.
How should I best handle this? Is there a way to tell when I need to use the SRV record resolver?
Alright, I figured out a way to identify the server by contacting it via https and then checking its certificate. That should be pretty reliable.
Below the code I use, though I ran into one complication: The mount URL I get for my QNAP NAS is: "QNAS._smb._tcp.local", but that is not a valid host name I can use in a NSURLRequest!
I need to transform that into the actual host name, which is "QNAS.local". Since the former is a Bonjour related name, and when I browse the Bonjour registry with BonJeff, I can find the mapping, this seems to be an overly complicated method. I wonder what the proper way is to get the basic host name from such a service name. I've googled for a while but could not find anything about it. For now, I simply remove all components from the host name that start with an underscore, but I'm not sure if that's a safe method.
#import <NetFS/NetFS.h>
#import <Security/Security.h>
#import "AppDelegate.h"
@interface AppDelegate () <NSURLSessionDelegate>
@end
@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
CFURLRef furl = CFURLCreateWithFileSystemPath(NULL, CFSTR("/Volumes/TheNAS"), kCFURLPOSIXPathStyle, true);
NSURL *url = CFBridgingRelease(NetFSCopyURLForRemountingVolume (furl));
NSArray *parts = [[url.host componentsSeparatedByString:@"."] filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(NSString* _Nullable part, id _Nullable bindings) {
return ![part hasPrefix:@"_"];
}]];
NSString *addr = [parts componentsJoinedByString:@"."];
NSLog(@"host: %@ -> %@", url.host, addr);
NSMutableURLRequest *request = [[NSMutableURLRequest alloc] init];
[request setURL:[NSURL URLWithString:[NSString stringWithFormat:@"https://%@", addr]]];
NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:nil];
[[session dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
NSLog(@"Done.");
[NSApp terminate:self];
}] resume];
}
-(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler
{
SecTrustRef trustRef = [[challenge protectionSpace] serverTrust];
SecCertificateRef certRef = SecTrustGetCertificateAtIndex(trustRef, 0);
CFStringRef name = nil;
SecCertificateCopyCommonName(certRef, &name);
NSLog(@"name: %@", name);
// reject the challenge because we have all we wanted
completionHandler (NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil);
}
@end
Oh hell! It's not my fault, it's Apple's. The signature appears to be outdated, or refences an expired cert. The fix is to temporarily change the system date to before Oct 1, 2019 for the installation.
Post not yet marked as solved
Just a guess:
Since /System/Volumes/Data/ contents are merged into /, you need to replace those paths accordingly (i.e. replace that long prefer in a path with the root path), and then you'll probably get permission.
If that works, then I suspect that the Sandbox path access validation code has not been updated to match these aliased paths when volume groups were introduced. I've run into several related issues, outside sandbox, and need to employ similar work-arounds.
One would hope that Apple would provide APIs for determining the members and paths of volume groups, and conversion methods, but that's not happening (see also https://stackoverflow.com/q/63876549/43615)
Oh, and if you don't like the path replacement method, you could also try getting the CanonicalPath instead - that should also point to the regular path, but take more time than the simple string replacement. If you only do this for a few bookmarks, that shouldn't have an impact and is safer.
In fact, there are two ways I use in my apps to get the canonical path. I don't remember which one works, so try them both:
Get the fileReferenceURL
This code (see also https://stackoverflow.com/questions/64720189):
NSString* canonicalFilePath (NSURL *url)
{
// Caution: Will expand /var/ into /private/var/
NSString *result = nil;
if (@available(macOS 10.12, *)) {
NSString *cpath;
if ([url getResourceValue:&cpath forKey:NSURLCanonicalPathKey error:nil] && cpath) {
result = cpath;
} else {
result = url.URLByResolvingSymlinksInPath.path;
}
} else {
result = [[url fileReferenceURL] filePathURL].path;
}
return result;
}
It is important to note that apps with Dock Tile plugins are not allowed in the Mac App Store! So don't waste your time on this if you plan to publish your app only in the MAS.
Post not yet marked as solved
To those who need an answer on how to conditionally compile depending on the used SDK version, here's what I found to work:
#if __MAC_OS_X_VERSION_MAX_ALLOWED >= 120000
// ... compiles only when using the macOS12.0 SDK (or later) that comes with Xcode 13.1
#endif
Post not yet marked as solved
I just got this as well from a user of my app (Find Any File).
Attached.
This happened when a user wanted to copy an unknown number of file references to the pasteboard.
Note that the app memory is around 18 GB. I wonder if the number of copied items is so large that the Mac simply ran out of memory.
faf.crash
Post not yet marked as solved
Just to double check: Your helpers are signed with the same cert as the main app is, right?
Post not yet marked as solved
Just to add some clarification: Apps that run their helper tools via NSTask seem not be affected. At least my app Find Any File remains able to launch its "searchfs" helper this way, which in turn searches entire volumes, once the main app has gotten FDA, even in 11.4.
I suspect that the issue is only with helpers that get run outside of the main app's runtime, e.g. as launchd service, Login Item etc.
This change was apparently implemented to deal with CVE-2021-30713: (see https://mjtsai.com/blog/2021/06/01/macos-11-4-breaks-full-disk-access-for-helper-tools/#comment-3465367). But in a wrong way: Instead of making sure that embedded helpers are tested to belong to the main app, i.e. have the same codesign Team ID, it simply denies them FDA altogether if they're launched not directly by the main app, it seems. Looks like a hasty fix that was not well thought through. And bug reports about it then being ignored as well. Scary.
Post not yet marked as solved
One thing I found that is not right: I am setting the doubleClick action handler in code, but I forgot to also set the control's target property. Still, when I run the code in the debugger, the action handler gets called even without having assigned the target.
So I wonder if that might be the cause of the issue. But if the responder chain was temporarily changed so that the action handler would get called on an object that doesn't implement the action, then I should get an exception about the missing selector (which is pathCellDoubleClicked: in my case), right? But that's not the case as far as I can tell, so I guess the unset target is not the cause here. Or am I wrong?
Post not yet marked as solved
So now I see that there's a special DTK tag (Universal App Quick Start). But I can't add it now. This forum system is so confusing to me.
